test: the ledger records which majors each check exists on (#1010) - #1019

Step 2 of #1010. Depends on #1013 (the first two commits) -- do not merge this before it
if you want them reviewed apart. The three commits that are this change are
ce2be2e5, f5b09c80, 0812c57d.

suite<TAB>part<TAB>name<TAB>majors<TAB>last-red<TAB>mutations

The major is a FIELD, not part of the key

A check's existence depends on the major, so the ledger has to record where a check
exists. It does not follow that the major belongs in the key, and the measurement decides it.

Full matrix at 4d7c75ae, 252 suites on PG15 and PG18: 6367 of 6472 checks are identical
on both majors and 105 exist on exactly one. A (major, suite, part, name) key would hold
5 copies of one observation for 98% of the file.

On today's coverage, measured from the migration itself:

1166 checks  ->  1166 rows under (suite, part, name)
1166 checks  ->  5830 rows under (major, suite, part, name)     exactly 5x

Across the whole tree the five-major logs hold 7795 distinct checks, which a pair key would
store as 31357 rows.

Keeping the key also keeps checks_never_observed_red counting CHECKS. Under a pair key
it would count pairs, and "5800 checks" in a tree holding 1150 of them is a number that lies
by its own name -- the defect check_ledger_budget.txt exists to argue against. No budget
key is renamed and the census does not move.

The field is a sorted ;-separated SET and it accumulates. A plain assignment was
measured doing the wrong thing to last-red on #918: merging a PG15 log after a PG18 log must
not make the check stop existing on 18, because the order somebody merges logs in is not a
fact about the code.

No wildcard. "Every major observed" would change meaning the day a major joins the
matrix, inheriting a claim nothing measured.

What it fixes is orphan-scan, not gate

The gate refuses a check in the LOG the ledger has not seen, and a PG18-only check does not
appear in a PG15 log -- so it stayed correct by never being asked. orphan-scan asks the
opposite question, and a PG18-only row is exactly what a deleted check looks like on PG15.

It was saved only by the SKIP rule, and that was luck: analyze_differential emits a
check_skip on PG15-17 so its part was unprunable, while fk_referencing:287 emits
check and has no SKIP at all -- 24 keys shared, 2 only on PG18, 1 only on PG15. Once that
suite is seeded, a PG15 run would have called its two PG17+ checks deleted.

The fourth category already said the true thing ("this run does not contain them, so it
cannot speak about them"), so the scope gains an intersection and nothing else: no new
category and no grandfather rule.

The gate also cannot refuse a check on a major it holds no rows for, for the same reason it
cannot in a suite it has never seen -- otherwise adding PG20 reddens every check at once,
which is a gate somebody turns off. It says out loud when it is not enforcing.

The migration

Derived from a five-major matrix on step 1's tree, 252 suite logs per major:

rows            1166 -> 1166   (carried 1166, added 0)
census          1164 -> 1164   (unchanged)
ever red           2 ->    2   (both carried, with their dates)
major sets      1166 x "15;16;17;18;19"

Every row claims all five majors because all three covered suites are major-invariant:
harness_selftest 916, differential 204, native_join_runtime_filter 46, identical on
15/16/17/18/19. So the diff is one field added per line.

It fails closed rather than guessing: a committed row observed on no major refuses the
whole run and prints the rows, because absence is not removal and a placeholder major would
be a claim nothing measured. It refused nothing here -- all 1166 were observed.

It also refuses to widen coverage. The logs carry all 252 suites; seeding them would take
the ledger to 7795 rows and drop suites_not_covered from 249 to nearly nothing, making
several thousand checks gate-enforced in a diff nobody could review. 6629 observed checks
outside the three covered suites were deliberately not seeded.

Test plan

• 22 pytest ledger tests, 133 checks, 0 fail, including three new ones: the set
  accumulates; a run speaks only for the majors a row claims; the gate cannot refuse on
  an uncovered major. Each carries a CONTROL -- without them the first proves only that
  nothing is ever an orphan and the third only that the gate refuses nothing.
• ~20 new shell arms in part 410 covering the same properties from the other harness,
  plus the invalid-major and no-major row refusals with an unknown control.
• Five-major matrix for the derivation: 252 suite logs each, 6660-6787 records per major.
• docs_style.sh PASSED.
• Matrix on the migrated ledger -- queued; step 1's own matrix is the evidence for the
  record format and this changes only the ledger the gate reads.

A correction carried in the second commit

I justified the unknown token by grepping harness_selftest.sh for PGC_MAJOR, finding
none, and concluding its 907 records carry it. That went into eight places before one awk
over a log already on disk disproved it: all 916 carry the real major, because 10 of its 46
parts call pgc_setup and parts share one shell. The truth is 14 other suites that need
no cluster -- 544 of 6753 records. All eight are corrected.

The measurement also showed something I would not have guessed: unknown versus a number is
order-dependent in any suite sourcing parts into one shell. A part added ahead of the
first pgc_setup would emit unknown where the ledger expects a number.

Also corrects orphan-scan's docstring, which named part 340's stand-in skip name as a
present-tense blocker to arming it. #994 and #998 removed that. Arming is now a decision
rather than a dependency, and it is not taken here -- filed as #1015, because "the one
blocker I measured is gone" is not the same claim as "no blocker remains".

🤖 Generated with Claude Code

https://claude.ai/code/session_01Uf6UoeBRZYLQZa4KxNiw8a